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Executive  Summary 


.  Image  processing  is  rapidly  emerging  as  a  field  with  many  interesting  areas 
for  the  computer  scientist.  Packages  are  available  that  allow  images  to  be 
manipulated  in  an  interactive  environment  by  applying  functions  to  the  image. 
Functions  are  defined  as  transformations  from  the  image  memory  domain 
to  the  display  domain,  which  may  permanently  alter  image  memory  values. 
This  paper  describes  minimum  hardware  constraints  and  the  scope  of  modifica¬ 
tions  necessary  to  implement  different  image  processors  within  the  Earth 
Resources  Laboratory  Applications  Software  (ELAS)  environment.  It  also 
contrasts  the  impact  on  software  engineering  principles  related  to  the  implemen¬ 
tation  of  low-level  software  to  support  the  imaging  functions. 
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Implementation  Issues  for  Level  0  Image 
Processor  Software  within  an  Application  Package 


Background 

ELAS  is  an  image  manipulation  package  originally 
developed  by  the  Earth  Resources  Laboratory  (ERL). 
The  package  is  comprised  of  over  600  modules.  Mod¬ 
ules  are  written  in  FORTRAN  4  and  the  host  assembler 
language.  The  Pattern  Analysis  Laboratory  (PAL)  of 
the  Naval  Ocean  Research  and  Development  Activity 
(NORDA)  needed  to  secure  ELAS  to  support  research 
in  the  determination  of  bathymetry  from  Landsat  and 
Thematic  Mapper  data.  The  host  machine  was  a  VAX 
1 1/780  with  a  Gould  IP  8500  image  processor.  Subse¬ 
quently  another  version  of  ELAS  was  developed  on 
a  VAX  1 1/750  with  a  Grinnell  275  image  processor. 
This  report  discusses  the  implementation  of  both 
systems  through  the  development  cycle  and  related  soft¬ 
ware  engineering  issues.  It  is  a  comparison  of  hard¬ 
ware  and  low-level  interfaces  between  the  two 
machines,  and  a  description  of  that  impact  on  the  soft¬ 
ware  engineering-related  issues. 


Theory  of  Operation 

El  AS  is  comprised  of  two  types  of  routines:  modules 
and  callable  subroutines.  Modules  are  scheduled  by  the 
currently  running  process  and  the  state  is  saved  in  a 
system  of  subfiles.  Scheduling  results  from  typing  in 
the  name  of  a  major  module  as  the  next  command  to 
process. 

Within  the  context  of  1  O  in  the  ELAS  image- 
manipulation  system,  COMD  is  the  common  image 
display  module  and  LABL  is  the  textual  graphics  and 
vector  drawing  module.  Each  of  these  modules  inter¬ 
face  with  a  low-level,  callable  subroutine,  CIO,  that 
provides  a  common  I  T)  interface  to  the  image 
processor. 


Software  Scope 

The  bulk  of  the  programming  effort  provided 
subroutines  CIO.  ZOOM,  RDSTAT,  and  ERKIN  I , 
which  were  not  present  and  which  were  written  in 
EORTRAN  77.  This  necessitated  changes  to  modules 
ELAS.  (  OMD,  LABI.,  and  FMGK.  Changes  were  also 


necessary  in  subroutines  RT,  CURDIF,  DIS1NT, 
FUNMEM,  and  FUNM2,  GWR1T2. 

Modules  ELAS,  FMGR,  and  RT  were  originally 
written  for  a  512  x  256  pixel  image  processor  with 
fewer  image  and  graphics  planes.  Changes  in  these 
modules  involved  defining  the  number  and  size  of 
image  planes  and  the  number  of  peripherals.  The  driver 
name  and  setup  codes  also  had  to  be  changed  to  reflect 
the  particular  image  processor  in  use. 

Modules  COMD  and  LABL  were  modified  to  allow 
zoom  and  scroll  capability  and  to  allow  hardware  to 
clear  image  and  graphics  planes,  which  increased  the 
speed  of  these  operations  considerably.  The  build  table 
section  was  updated  to  allow  color  table  values  from 
0  to  255  instead  of  the  0  to  15  range  previously 
implemented.  The  print  color  table  section  was 
enhanced  to  print  values  from  0  to  255  rather  than  0  to 
15.  Finally,  these  modules  were  changed  to  use  a 
trackball  interface  for  determining  cursor  position 
rather  than  ASCII  characters  from  the  VT100 
keyboard. 

Subroutines  CURDIF,  DISINT,  FUNMEM,  and 
FUNM2  were  also  changed  to  use  the  trackball  inter¬ 
face  instead  of  ASCII  sequences  from  the  terminal. 

Subroutine  GWRIT2  was  modified  to  pass  4-bytc 
parameters  to  1LBJT  to  allow  correct  subroutine 
linkage.  Previously  implemented  versions  of  GWR1T2 
were  developed  on  older  PDP-1 1  machines  which  used 
a  16-bit  word  rather  than  the  standard  32-bit  word  used 
on  the  VAX  architecture.  Problems  in  this  area 
manifest  themselves  in  a  unique  way  because  the  VAX 
architecture  stores  its  most  significant  bits  in  the  lowest 
address.  Thus  a  valid  integer  passed  to  an  ILBIT 
became  a  zero  or  a  large  negative  number  in  that 
routine’s  formal  parameter  list.  The  value  erroneously 
passed  depends  on  the  value  of  the  integer  in  the  call¬ 
ing  routine.  This  change  corrected  a  problem  encoun¬ 
tered  with  writing  graphics  in  the  vertical  direction. 

An  additional  software  change  was  a  modification 
to  GRDRV,  the  DR1I-B  driver.  The  driver  was 
modified  to  provide  compatibility  with  the  VMS  4.2 
opetating  system.  SDYNDEF  was  added  to  the  driver 
to  map  in  the  dynamic  definitions  that  were  resident 
in  a  different  library  in  the  VMS  3.6  software. 


Hardware  Scope 

The  existing  hardware  configuration  did  not  have 
sufficient  lookup  tables  to  simultaneously  map  an 
intensity  scale  function  and  a  color  lookup  function. 
This  is  because  the  only  lookup  tables  available  were 
on  the  image  function  memory  board  and  only  one 
function  could  be  loaded  at  a  time.  Another  set  of  func¬ 
tions  was  available  on  the  image  processor  card,  but 
the  output  of  these  tables  is  routed  back  to  the  image 
planes,  permanently  altering  their  values.  This  was  con¬ 
sidered  an  unacceptable  approach  during  true  color 
operation  because  three  image  planes  are  used  to  hold 
the  RGB  spectrum  and  three  scratch  planes  would  also 
be  needed.  The  Grinnell  has  only  five  image  planes. 

The  cleanest  solution  and  the  one  implemented  was 
to  change  the  image  video  driver  board  to  a  function 
video  driver  board.  The  boards  operate  identically  but 
the  function  video  driver  board  provides  another  set 
of  lookup  tables  to  the  system.  There  was  a  problem 
associated  with  the  implementation:  slot  #33  did  not 
have  read-back  lines  or  control  signals  for  the  lookup 
tables.  This  problem  was  solved  by  modifying  the  back 
plane  to  accommodate  those  signals  to  the  slot.  The 
system  now  provides  two  sets  of  lookup  tables  to  the 
system  in  a  sequential  path  from  image  memory  to  the 
video  drivers.  Appendix  A  documents  the  changes  nec¬ 
essary  to  reconfigure  the  Grinnell  image  processor  for 
the  function  video  driver  board. 

The  trackball  interface  provided  an  additional  set 
of  problems.  There  is  a  hardware-design-related  prob¬ 
lem  with  polling  the  trackball  interrupt  registers.  The 
enter  push-button  switch  must  be  depressed  before  any 
other  switches  can  be  sensed  in  the  interface  register. 
Two  resistor  packs  were  used  in  the  trackball,  -1  and 
3  types.  They  both  have  16  pins  but  the  -3  has 
8  resistors  in  the  bridge  instead  of  15.  This  causes  a 
timing  problem  when  reading  the  trackball  interrupt 
register,  specifically  the  enter  button.  Consequently  the 
interface  loses  synchronization  with  the  system- 
provided  QIO  and  a  successful  read  does  not  take 
place.  The  problem  is  then  complicated  by  the  fact  that 
(,MO  thinks  it  got  a  successful  read,  as  signified  by  the 
lO-status  block  word  one,  and  the  number  of  bytes 
read  is  signified  by  word  two.  This  means  that  the 
system  service  routine  SSVNCH  cannot  be  used  to  indi¬ 
cate  either  condition.  The  problem  did  not  respond  to 
the  use  of  event  flags  since  the  QIO  routine  believes 
it  is  getting  a  valid  read.  Slowing  the  loop  down  by 
initiating  a  SWAITFR  (or  a  do-nothing  loop)  eliminates 
the  problem  and  does  not  seem  to  affect  the  use  of  the 
trackball  with  HI  VS  One  is  primarily  interested  in  the 
state  at  that  time  and  not  in  obtaining  an  interrupt. 
Slowing  down  the  loop  also  precluded  multiple  reads 
in  a  loop  as  an  approach  with  a  limit  on  the  number 
ot  reads.  The  delay  docs  not  adversely  impact  perform¬ 
ance.  7  he  resolution  of  this  problem  was  very  time  and 
labor  intensive. 


Software  Engineering  Issues 

A  variety  of  lessons  can  be  learned  from  the  imple¬ 
mentation  of  ELAS  in  an  environment  with  a  specific 
image  processor.  The  hardware  and  software  support 
offered  by  a  vendor  may  dictate  design  issues  so  that 
a  clean  implementation  cannot  be  achieved.  This  can 
be  experienced  with  other  image-processing  packages 
as  well. 

Vendor  software  is  a  major  issue  in  the  decision  to 
buy  a  particular  piece  of  hardware.  However,  it  may 
be  preferable  to  implement  your  own  software  solu¬ 
tions  because  of  the  level  of  complexity  that  may  be 
added  to  the  software  package.  Complexity  is  deter¬ 
mined  by  communication  structures  used  by  designers 
of  the  user  package  and  the  image-processing  vendor’s 
library. 

In  modern  software  packages,  communication 
between  different  independent  routines  is  achieved  by 
message  passing  schemes.  These  are  usually  global  or 
common  variables,  depending  on  the  language  choice, 
and  are  true  of  both  interactive  and  library  callable 
subroutines.  To  use  the  vendor-supplied  routines,  the 
message  system  must  be  established  by  the  application 
software  package,  which  creates  a  structure  on  top  of 
the  user  package,  which  obviously  fails  to  localize  the 
functions  of  the  image  processor  with  relationship  to 
the  other  software  in  the  user  package.  This  method 
is  wrong  from  a  software  engineering  viewpoint  for 
two  reasons:  complexity  and  control  of  data  How. 

Complexity  is  increased  by  many  factors  that  pre¬ 
sent  at  least  two  alternatives.  First,  the  software  main- 
tainer  must  know  in  an  intimate  way  two  different  user 
packages.  Thus,  the  programmer  must  know  the  image- 
processing  system  even  if  the  primary  interest  is  in  the 
development  of  statistical  manipulation  capabilities  for 
the  system.  The  other  alternative  is  to  have  two  dif¬ 
ferent  people  responsible  for  maintenance  of  the 
system,  neither  of  whom  is  fully  skilled  to  handle  prob¬ 
lems  in  other  parts  of  the  software.  The  second  alter¬ 
native  impedes  the  speed  of  problem  determination  and 
may  have  great  impact  in  a  production  environment. 
Also,  there  could  be  more  overhead  in  communication 
between  programmers  assigned  to  modify  or  maintain 
the  software,  including  a  lengthened  learning  curve. 

Good  software  practice  demands  that  a  module 
receive  information  on  a  need-to-know  basis.  At  the 
very  least,  write-access  to  a  variable  should  be  limited 
and  regulated  by  a  good  design  methodology.  Adding 
a  layer  of  variables  for  message-passing  schemes  places 
the  entire  structure  in  a  wide-open  environment.  The 
latter  may  cause  a  variety  of  problems,  including  distor¬ 
tion  of  the  message  if  the  variable’s  state  is  compro¬ 
mised.  and  in  a  large  system  it  could  be  extremely 
difficult  to  locate. 

f  urther,  placing  a  layer  on  top  of  the  applications 
package  completely  destroys  portability,  since  all 
modules  would  have  to  be  changed  to  accommodate 


a  new  vendor’s  message-passing  protocol.  It  must  also 
be  pointed  out  that  vendor  software  is  generally  pro¬ 
prietary  and  may  be  sold  separately  and  not  included 
with  the  hardware.  Portability  of  the  package  to 
another  lab  may  be  impossible  or  more  expensive; 
therefore,  display  routines  should  be  isolated  and  the 
vendor’s  library  should  be  used  only  when  the  goal  of 
portability  is  not  compromised. 

The  image-processing  system  can  be  likened  to  a 
layer  of  abstractions  from  the  software  interface  view¬ 
point.  The  Gould  IP8500  image  processor  provides  a 
level  0  function  IP8Q,  which  is  a  pseudo-driver  on  top 
of  the  VAX-supplied  QIO  routine.  The  parameters 
passed  to  IP8Q  include  mnemonics  that  tell  IP8Q  what 
function  to  perform  on  behalf  of  the  user’s  applica¬ 
tion.  It  may  take  several  calls  to  affect  a  principal  func¬ 
tion  of  the  image  processor.  The  system  also  provides 
parameters  for  selecting  the  register  and  the  board  to 
modify  where  a  polyboard  or  polyregister  environment 
exists.  Thus,  modification  to  a  particular  register  on 
a  particular  board  causes  a  unique  function  of  the 
imaging  system  to  occur  (i.e.,  reading  an  image  into 
image  memory).  The  IP8Q  is  performing  the  task  of 
packaging  bit  patterns  that  the  machine  can  under¬ 
stand  and  handing  them  to  QIO.  In  this  manner  the 
mnemonics  generate  streams  of  bit  patterns  which, 
packaged  with  other  parameters,  instruct  the  machine 
to  perform  a  particular  function.  Grouping  these  calls 
together  formulates  level  1  calls,  which  are  a  level  of 
abstraction  higher  than  level  0  calls. 

The  Grinnell  GMR275  does  not  provide  an  abstrac¬ 
tion  at  this  level.  Therefore,  it  was  necessary  to  form 
an  array  of  bit  patterns  and  pass  the  array  to  QIO. 
Mnemonics  for  each  primitive  instruction  on  the  boards 
are  associated  with  a  hexidecimal  code  representing  that 
instruction’s  opcode.  Specific  instructions  are  formed 
by  logically  “and-ing”  or  logically  “or-ing”  a 
parameter  with  an  instruction  mask.  In  this  vein, 
streams  of  instructions  are  generated  to  effect  a  ma¬ 
jor  component  of  the  imaging  engine.  Thus,  func¬ 
tionality  of  instruction  packets  were  made  isomorphic 
to  the  functions  of  the  Gould  I P8500  though  individual 
instructions  were  not  isomorphic. 

To  modularize  the  functionality  of  the  common  I/O 
interface  (CIO)  for  the  Grinnell,  a  strategy  of  localiza¬ 
tion  was  adopted.  Initialization  during  each  major 
function  was  performed  within  that  stream  of  instruc¬ 
tions.  which  made  each  function  of  CIO  completely 
contained  within  that  portion  of  the  code  rather  than 
relying  on  initialization  coming  into  the  routine  at  the 
top.  This  allowed  an  extremely  crisp  case  structure  to 
be  implemented  with  a  computed  GOTO,  and,  together 
with  the  use  of  mnemonics,  made  the  development 
quick  and  easy  since  all  logic  problems  were  isolated 
within  a  small  section  ot  code  within  the  routine. 


Conclusions 

A  wide  variety  of  image  processors  are  on  the  market 
ranging  in  price  from  a  few  thousand  to  several  hun¬ 
dred  thousand  dollars.  The  higher-priced  systems 
provide  hardware-implemented  solutions  to  software- 
related  problems  such  as  histogram  equalization  or 
warping  and  stretching.  In  order  for  the  image- 
manipulation  packages  to  remain  independent  they 
must  continue  to  provide  these  functions  in  software. 
This  lessens  the  risk  of  becoming  a  hardware-dependent 
package.  While  not  machine  specific,  ELAS  is  architec¬ 
ture  specific,  treating  the  image  processor  as  just  a 
frame  buffer.  This  attitude  should  be  relaxed  to  begin 
taking  advantage  of  the  tremendous  advances  in  to¬ 
day’s  machines.  However,  most  applications  in  the 
image-processing  domain  do  not  require  instantaneous 
results  so  the  lack  of  hardware  functions  does  not 
significantly  degrade  the  capacity  to  use  the  package. 
It  is  recommended  that  these  advanced  features  be 
viewed  as  trade-offs  in  terms  of  throughput.  Cheaper 
hardware  costs  allow  more  workstations,  which  may 
provide  more  throughput  than  a  single  machine  run¬ 
ning  at  the  state  of  the  art.  However  a  minimum  con¬ 
figuration  should  include  the  following: 

1 .  A  single  video  output  controller  for  each 
workstation. 

2.  Four  512  x  512  by  eight-bits-deep  image  planes 
for  each  work  station  (three  planes  configured  for  RGB 
and  one  plane  for  graphics). 

3.  Two  sets  of  lookup  tables,  one  for  functions  and 
one  for  color  mapping,  available  to  each  workstation. 
The  tables  should  each  be  256  x  8  bits  deep.  The  color 
lookup  table  should  contain  three  256  x  8-bits-deep 
tables. 

4.  One  trackball  interface  with  multiple  interrupt 
buttons. 

5.  A  monitor  capable  of  displaying  512  x  512  by 
eight  bits  deep  at  one  time.  However  most  packages 
are  moving  toward  a  1024  x  1024  by  twelve-bits-deep 
display. 

Beyond  these  considerations,  speed  versus  price 
becomes  an  issue.  The  time  required  to  classify  an 
image  with  the  iterative  maximum  likelihood  estimators 
grows  nonlinearly.  Thus  an  increase  in  the  display  size 
will  cause  computational  time  to  grow  by  more  than 
a  factor  of  two. 

It  may  become  economical  to  include  such  features 
as  an  array  processor  board  or  a  histogram  equaliza¬ 
tion  board.  Image  windowing  can  also  come  in  handy 
when  large  files  are  to  be  zoomed  and  scrolled. 

The  standard  configuration  of  a  vendor's  image 
processor  should  be  carefully  scrutinized.  They  do  not 
all  provide  standard  hardware  features.  The  Grinnell 
GMR  275  image  processor  is  a  prime  example.  It  pro¬ 
vided  only  one  set  of  lookup  tables,  which  made  a 
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backplane  modification  and  a  board  purchase  neces¬ 
sary.  The  type  of  output  also  should  be  checked. 
Vendors  usually  supply  RS-170A,  30-Hz  interleaved, 
or  60  Hz  noninterleaved.  Some  vendors  supply  a 
combination  of  RS-170  and  one  of  the  other  two. 

Turning  to  software  engineering  issues,  portability 
cannot  be  maintained  if  the  vendor’s  package  is  placed 
on  top  of  the  existing  applications  package.  This  would 
limit  the  user  to  systems  with  similar  hardware.  It  was 
also  pointed  out  earlier  in  this  paper  that  placing  the 
vendor’s  package  on  top  of  the  existing  imaging 
package  unnecessarily  adds  to  complexity;  therefore, 
it  should  be  avoided.  Avoidance  will  require  develop¬ 
ing  level  0  software  by  the  support  group  for  the  user 
application  package.  Price  being  equal,  the  software 
with  the  highest  level  of  abstraction  in  its  level  0  calls 
should  be  chosen,  since  it  will  minimize  the  develop¬ 
ment  cycle. 

Regarding  the  development  of  the  common  I/O 
interface,  the  assignment  of  opcodes  to  mnemonic 
names  increased  readability,  because  they  are  more 
descriptive  than  hexidecimal  codes.  Additionally,  there 
was  less  error  due  to  misdefining  the  opcodes  since, 


once  defined  properly,  they  became  a  nonissue  in  the 
development  cycle.  Quintessentially,  the  most  sig¬ 
nificant  contributing  factor  was  the  complete  isolation 
of  functions  within  the  routine.  There  were  a  number 
of  reasons.  First,  the  area  of  interest  was  localized  to 
a  block  of  code  rather  than  splitting  it  by  initializing 
at  the  top  section.  This  concentrates  functionality 
within  the  block  of  code  making  comprehension  much 
easier.  Second,  because  all  initialization  is  performed 
within  the  block,  the  effects  of  extraneous  values  left 
in  a  register  are  minimized.  This  provides  a  complete 
implementation  of  the  functional  subcomponents  in 
each  block  of  code.  Understandability  was  partitioned 
or  chunked  by  the  isolation,  which  implies  that  only 
that  subcomponent  of  interest  need  be  grasped  rather 
than  an  entire  routine.  The  image  processors  in  general 
are  faster  than  the  VAX  11/780.  Thus  duplication  of 
the  initialization,  which  amounted  to  a  few  additional 
lines  of  code,  is  negligible  because  initialization  at  the 
top  requires  FORTRAN  conditional  logic,  which  is 
slower  than  executing  three  or  four  additional  inline 
instructions  in  the  image  processor. 
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Appendix  A:  Wiring  Modifications  to 
the  Grinnell  GMR  275  Image  Processor 


nmrw  »  vnyf  tfi  n  v  um  \rm  imwim 


For  example:  33IPS34 


The  backplane  wiring  list  can  be  read  as  follows. 
Each  connector  has  two  rows  which  we  will  call  bot¬ 
tom  and  top.  The  bottom  row  is  designated  PS  while 
the  top  row  is  designated  CR. 

Each  row  has  two  connectors  which  we  will  call  left 
and  right.  The  left  connector  is  designated  by  the 
numeral  1  while  the  right  connector  is  designated  by 
the  numeral  2. 

On  each  connector  the  pins  are  labeled  from  1  to 
50  starting  on  the  bottom  row. 

The  first  two  numbers  represent  the  slot  number  for 
the  board. 


33  -*•  The  thirty-third  slot  on  the  backplane; 

1  -*•  The  left  side  connector; 

P  S~*  The  bottom  row  side; 

3  4~*  The  thirty-fourth  pin. 

The  modifications  are  marked  on  the  five  pages 
which  follow.  The  numbers  9XDB14  through  9XDB00 
are  the  designations  for  the  lookup  table  address  lines. 
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Appendix  B:  ELAS  Routines  Affected 
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C 

C 

C 
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CIO. FOR  FOR  THE  GRINNELL  IMAGE  DISPLAY 

CALL  CIO  (  LU,  IOP,  NC,  LINE,  NBTS,  BUFF,  L  ) 

LU  =  LOGICAL  UNIT  (  NOT  USED  ) 


IOP  =  COMTAL 


1 

2 

3 

4 

5 

6 
7 


FOR 

FOR 

FOR 

FOR 

FOR 

FOR 

FOR 


=  8  FOR 
=  9  FOR 
=  10  FOR 


OPERATION  CODE 
IMAGE  READ 
IMAGE  WRITE 
GRAPHIC  READ 
GRAPHIC  WRITE 
FUNCTION  READ 
FUNCTION  WRITE 
COLOR  TABLE  READ 
COLOR  TABLE  WRITE 
TARGET  READ  (  DISABLED  ) 
TARGET  WRITE 


NC 


LINE 


COMPONENT  NUMBER 

IMAGE  /  GRAPHIC  NUMBER  I  IOP  IS  1,2,3  OR  4 

ALSO  IF  NC  IS  NEGATIVE,  THE  SCROLL  REGISTER  WILL  BE 

UPDATED  AFTER  THE  OPERATION  TO  ALLOW  THE  IMAGE  TO  BE 

ROLLED. 

UNUSED  FOR  IOP  GREATER  THAN  4 

LINE  NUMBER  FOR  IMAGE  OR  GRAHIC  READ  OR  WRITE. 

THIS  NUMBER  IS  USED  AS  ELAS  EXPECTS.  I.E.  THE 
TOP  LINE  IS  LINE  0. 


NBTS  =  NUMBER  OF  BYTES  (  NOT  USED  ) 

BUFF  =  DATA  ARRAY 

L  =  STATUS  ;  NORMALLY  EQUAL  TO  NBTS  ;  NEGATIVE  ON  ERROR 

SUBROUTINE  CIO  (  LU,  IOP,  NC,  LINE,  NBTS,  BUFF,  L  ) 

IMPLICIT  INTEGER*4  (  A  -  Z  ) 

INTEGER*2  LN,  ELM 

INTEGER*2  GR,  IMG,  MASK,  COL,  BUFF(512),  B(600),  I0SB(4), 

*  WID,  LSM,  WGD,  WAC,  LWM,  LUM, 

*  ERS,  ERL,  SLU,  EGW,  LER,  LEA, 

*  LDC ,  NOP,  LPR ,  LPR1 ,  LPR2 ,  LPR3, 

*  LPR4,  LPR5 ,  SPD,  LPA,  LPD,  RPD, 

*  BIT  1 5 

THE  FOLLOWING  PARAMETERS  DEFINE  THE  GRINNEL  OPCODES  SYMBOLICLY. 


PARAMETER 
*( WID* '0000 'X, 

*  WAC* ' 2400 ' X , 

*  ERS= ' 3000 ' X , 


LSM= ' 1000 'X , 
LWM= ' 2800 ' X , 
ERL=' 3400 'X, 


WGD= ' 2000 'X, 
LUM='2C00'X, 
SLU= ' 3800'X , 


S8 

& 


3 

V 


*  EGW- ' 3C00 'X , 

*  LEB-  '  5000  '  X , 

*  LLA- ' 6800 ' X , 

*  LDC- '8000 'X , 

*  LPR1  - '  C200  'X  , 

*  LPR4«'C800 'X, 

*  LPD«'D000'X, 


LER-'4000'X,  LEA-' 4800 'X, 
LEC- ' 5800 'X ,  LLR-'6000'X, 

LLB- '  7000 'X ,  LLO'7800'X, 

NOP- '9000 'X,  LPR»'C000'X, 

LPR2-' C400 'X ,  LPR3- 'C600 'X, 
SPD-'AOOO'X,  LPA-'BOOO'X, 
RPD-'EOOO'X, 


BIT  MASKS 
*  B IT1 5- ' 8000 'X ) 

CB  IS  AN  ARRAY  USED  FOR  CFSUB  CALLS 
INTKGER*4  CB(4) 

FIRST  IS  USED  TO  TELL  CIO  WHEN  IT  IS  FIRST  CALLED. 

DATA  FIRST  /O/ 

DATA  CB  /  4H1FCT, 0,0,0/ 

DATA  TCH/1/ 

EXTERNAL  IO$_READLBLK 
EXTERNAL  IO$_WRITELRLK 

IF  THIS  IS  THE  FIRST  TIME  INTO  CIO,  OPEN  THE  GRINNKL 

IF  (  FIRST. EQ.O  )  THEN 

L  =  SYS$ASSIGN  (  ' CRAO : '  ,GR_LIJ ,  ,  ) 

IF  (  L.NE.l  )  THEN 
WRITE  (  6,1)  L 

FORMATC  UNABLE  TO  ASSIGN  THE  GRTNNKLL;  STATUS  >=  ’,7.8  ) 
F.I.SE 

FIRST  -  1 
END  IF 
END  IF 


GO  TO  (100,  200,  300,  400,  300,  600,  700,  800,  900, 
k  1000,  1100,  1200,  1300),  IOP 


READ  IMAGE 


100  CONTINUE 


LN  - 

31 

!  - 

L 

INE 

IMG 

- 

ABS 

(NC) 

IMG 

= 

2  ** 

(  IMG 

-  0 

B(  1  ) 

S3 

I  OR 

( 

LWM, 

CM 

C 

c 

'X 

) 

B(  2) 

- 

I  OR 

( 

LUM, 

'0002 

’X 

) 

B(  3) 

at 

I  OR 

( 

LLA, 

LN 

) 

B(4) 

S3* 

I  OR 

( 

LEA, 

'0001 

’X 

) 

B(5) 

S3 

TOR 

( 

LEB, 

'0001 

•x 

) 

B(  6 ) 

IS 

TOR 

( 

LDC , 

IMG 

) 

REVERSE  ORDER  TO  MATCH  ELAS 
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B( 7 )  -  IOR  (  LSM,  'OOFF'X  ) 

B(8)  -  TOR  (  SPD,  'OlOO'X  ) 

8(9)  =  IOR  (  RPD,  'OOOO 'X  ) 

STAT  =  SYS$QIOW  (  ,  2VAL(  GR_LU  ),  IO$_WRITELBLK  , 

*  LOSB, , ,B,  %VAL(  18  ),,,,) 

STAT  =  SYS$QIOW  (  ,  %VAL(  GR_LU  ) , IO$_READLBLK, 

*  IOSB , , ,  B  ,  %VAL  (  1024  ),,,,) 

CALI,  CIOPCK  (  B,  BUFF,  512  ) 

L  -  512 
RETURN 
C 

C  WRITE  IMAGE 
C 

200  CONTINUE 

LN  =  511  -  LINE  !  REVERSE  ORDER  TO  MATCH  ELAS 

IMG  =  ABS  (NC) 

IMG  =  2  **  (IMG  -  1) 

B(l)  =  IOR  (  LWM,  '0000 'X  ) 

B( 2 )  =  TOR  (  LUM,  '0002'X  ) 

B( 3)  =  IOR  (  LLA,  LN  ) 

B(4)  =  IOR  (  LEA,  ’0000'X  ) 

B( 5)  =  IOR  (  LEB,  '0001 'X  ) 

B(6)  =  IOR  (  LDC,  IMG  ) 

B( 7 )  =  TOR  (  LSM,  ’OOFF'X  ) 

B(8)  =  IOR  (  SPD,  ' 0200 ' X  ) 

B(9)  =  IOR  (  LPR,  '0200 ' X  ) 

DO  I  =  1 ,  512 

B( 1+9)  =  BUFF(I) 

END  DO 

NTW  =  512  +  18 

STAT  =  SYS$QIOW  (  ,  %VAL(  GR_LIJ  ),  TO$_WRITELBLK  , 

*  IOSB, , ,B,%VAL(  NTW  ),,,,) 

L  -  512 

RETURN 

C 

C  READ  GRAPHICS 

C 

300  CONTINUE 

GR  =  ABS  (  NC  )  /  2 
GR  =  2**(GR  +  8) 

LN  =  511  -  LINE  !  REVERSE  ORDER  TO  MATCH  EI.AS 


B(!) 

= 

IOR 

( 

SPD, 

'000  1  'X 

) 

B(  2) 

= 

IOR 

( 

LPR  1  , 

'OOCO'X 

) 

B(  3) 

= 

IOR 

( 

LPR2 , 

'OOAO'X 

) 

B  ( 4 ) 

= 

IOR 

( 

LPR3, 

'0010'X 

) 

B(5 ) 

= 

IOR 

( 

LDC, 

GR 

) 

B(6) 

= 

IOR 

( 

LSM, 

'OFOO'X 

) 

B(7) 

= 

IOR 

( 

LEA, 

'0001 'X 

) 

B(8) 

= 

IOR 

( 

LLA, 

LN 

) 

B(  9 ) 

= 

IOR 

( 

LEB , 

'0001 'X 

) 

B(  10) 

= 

IOR 

( 

LLB, 

'0000 'X 

) 

B(  1  1) 

= 

IOR 

( 

LUM, 

'0002 'X 

) 

B(  12) 

= 

IOR 

( 

LWM, 

'0840  'X 

) 

B(  1  3) 

= 

IOR 

( 

SPD, 

'  0 1 00  '  X 

) 

1 


B( 14)  -  IOR  (  RPD,  'OCOO'X  ) 

STAT  =  SYS$QIOW  (  ,  %VAL(  GR_LU  ),  IO$_WRITELBLK  , 
k  IOSB , , ,  B ,  %VAL(  28  ),,,,) 

STAT  =  SYS$QIOW  (  ,  %VAL(  GR_LU  ) , IO$_READLBLK, 

*  IOSB , , ,  B ,  %VAL  (  512  ),,,,) 

CALL  CIOGPK  (  B,  BUFF,  512  ) 

CALL  SWL  (  BUFF,  64  ) 

L  =  64 
RETURN 

WRITE  GRAPHICS 


400  CONTINUE 

CALL  SWL  (  BUFF,  6 
GR  =  ABS  (  NC  )  / 
GR  =  2**(GR  +  8) 

LN  =  511  -  LINE 
B(  1)  =  IOR  (  SPD , 

B(  2)  =  IOR  (  LPR1 

B( 3)  =  IOR  (  LPR2 

B(  4)  =  IOR  (  LPR3 

B(5)  =  IOR  (  LDC, 

B( 6)  =  IOR  (  LSM, 


REVERSE  ORDER  TO  MATCH  ELAS 


B(  L) 

B(  2) 
B(  3) 

B(  4) 

B(  5 ) 

B(  6) 

B(  7) 

B(  8 ) 
B(9) 

B(  10) 
B(  1  1  ) 
B(  12) 
B(  1  3) 
B(  14) 
DO  I  ■ 


SPD,  ’0001’X  ) 
LPR1 , 'OOCF'X  ) 
LPR2,'00AF'X  ) 
LPR3, 'OOIF'X  ) 
LDC,  GR  ) 
LSM,  'OFOO'X  ) 


=  IOR  (  LEA, 
=  IOR  (  LLA, 
=  IOR  (  LEB, 
=  IOR  (  LLB , 
=  IOR  (  LUM, 
=  IOR  (  LWM, 
=  IOR  (  SPD, 
=  IOR  (  LPR, 
=  1,32 


'0000 'X  ) 
LN  ) 
'0008 'X  ) 
'OOOO'X  ) 
'0002 ’X  ) 
'0840  *X  ) 
'0200'X  ) 
' 0820 'X  ) 


B( 1+14)  »  BUFF(I) 

END  DO 

NTW  =64+14 
NTW  =  NTW  *  2 

STAT  =  SYS$QIOW  (  ,  %VAL(  GR_LU  ) ,  IO$_WRITELBLK  , 

*  IOSB, , ,B ,  %VAL  (  NTW  ),,,,) 

CALL  SWL( BUFF , 64 ) 

L  =  64 
RETURN 

READ  FUNCTION 

SINCE  THE  GRINNELL  HAS  3  LOOKUP  TABLES  WHICH  HAVE  BEEN 
IMPLEMENTED  TO  SERVE  AS  BOTH  FUNCTION  &  COLOR  TABLE, 
THE  READ  FUNCTION  IS  CODED  TO  READ  FROM  A  SUBFILE. 

500  CONTINUE 

CB( 3)  =  1 
CB( 4 )  =  128 

CALL  CFSUB  (  5,  CB,  BUFF  ) 

L  =  512 
RETURN 


y;y,y v.  -• 


WRITE  FUNCTION 

600  CONTINUE 

CB(3)  -  1 
CB(4)  =  128 

CALL  CFSUB  (  6,  CB,  BUFF  ) 

B( 1 )  =  IOR  (  SPD,  '0002 'X  ) 

B(2)  =  IOR  (  LPA,  'OCOO'X  ) 

DO  I  =  1,  256 

B( 1+2)  =  IOR  (  LPD,  BUFF(I)) 

END  DO 

NTW  =512+4 

STAT  =  SYS$QIOW  (  ,  %VAL(  GR_LU  ) , IO$_WRITELBLK  , 

*  IOSB , , , B ,  %VAL(  NTW  ),,,,) 

L  =  512 
RETURN 

READ  COLOR  TABLE 

THIS  OPTION  READS  FROM  A  SUBFILE  RATHER  THAN  THE  GRINNELL. 

700  CONTINUE 

CB( 3)  =  129 
CB(4 )  =  256 

CALL  CFSUB  (  5,  CB,  BUFF  ) 

L  =  512 
RETURN 


WRITE  COLOR  TABLE 


800  CONTINUE 

CB( 3)  =  129 
CB( 4 )  =  256 

CALL  CFSUB  (  6,  CB,  BUFF  ) 

B(  1)  =  IOR  (  SPD,  ’OOOl’X  ) 

DO  ICOL  =1,3 

MASK  =  (  ICOL  -  2  )  *  '80 0 ’X 
IF  (  MASK. LT. 0  )  MASK  =  ’400’X 
B( 2 )  =  IOR  (  LPA,  MASK  ) 

MASK  =  15  *  16**(  ICOL  -  1  ) 

DIV  =  16**(  ICOL  -  1  ) 

DO  LOC  =  1 ,  256 

COL  =  I AND  (  BUFF  (  LOC  ) ,  MASK  ) 

COL  =  COL  /  DIV  *  17 
B  (  LOC  +  2  )  =  IOR  (  LPD,  COL  ) 

END  DO 

NTW  =512+4 

STAT  =  SYS$QIOW  (  ,  %VAL(  GR_LU  ) , IO$_WRITELBLK , 
*  IOSB , , , B ,  %VAL(  NTW  ),,,,) 

END  DO 
L  =  512 
RETURN 

READ  TARGET  ONLY  ONE  CURSOR  OF  FOUR  ACTIVATED 


i 

TO 


-ft 


900  CONTINUE 


IOR  (  SPD,  ' 0080 'X  ) 

IOR  (  LPR,  '0011 ’X  ) 

IOR  (  LPA,  '0000 'X  ) 

IOR  (  RPD,  '0000' X  ) 

SYS$QIOW  (  ,  %VAL(  GR_LU  ) , I0$_WRITELBLK, 
IOSB , , ,B,  %VAL(  8  ),,,,) 


STAT  =  SYS$QIOW  (  ,  %VAL(  GR_LU  ) , IO$_READLBLK, 

*  IOSB,,,B,  %VAL(  4  ),,,,) 

BUFF( 1)  =  B( 1)  .AND.  1023 

BUFF( 2)  =  512  -  ( B( 2)  .AND.  1023) 

RETURN 

WRITE  TARGET 

1000  CONTINUE 

LN  =  512  -  BUFF  (2) 

ELM  =  BUFF(l) 

ELM  =  IOR  (  ELM,  '0800'X  ) 

LN  =  IOR  (  LN,  '0800 'X  ) 

PRINT*,'  X  AND  Y  ' , ELM, '  ' ,LN 

B ( 1 )  =  IOR  (  SPD,  '0080  'X  ) 

B( 2)  =  IOR  (  LPR,  '0011 'X  ) 

B(3)  =  IOR  (  LPA,  'OOOO'X  ) 

B(4)  =  IOR  (  LPD,  ELM  ) 

B(5)  =  IOR  (  LPD,  LN  ) 

STAT  =  SYS$QIOW  (  ,  %VAL(  GR_LU  ) , IO$_WRITELBLK, 

*  IOSB, , ,B,  %VAL(  10  ),,,,) 

RETURN 

ERASE  IMAGE  NO  LONGER  USED  SUBROUTINE  CLRGI  USED 

LEFT  IN  CASE  SOMEONE  HAS  OLDER  ROUTINES  WHICH  DO  NOT  CALL  CLRGI 

1  100  CONTINUE 

IMG  =  ABS(NC) 

IMG  =  2**( IMG  -  1 ) 

PRINT  *, '  IMG  =  ' ,IMG 
B( 1 )  =  IOR  (  LDC ,  IMG  ) 

B( 2)  =  IOR  (  LSM ,  'OOOF'X  ) 

B( 3 )  =  ERS 

STAT  =  SYS$Q IOW  (  ,  %VAL(  GR_LU  ) , IO$_WRITELBLK, 

*  IOSB , , , B ,  %VAL(  6  ),,,,) 

RETURN 

ERASE  GRAPHIC  NO  LONGER  USED  SUBROUTINE  CLRGI  USED 

LEFT  IN  CASE  SOMEONE  HAS  OLDER  ROUTINES  WHICH  DO  NOT  CALL  CLRGI 

1200  CONTINUE 

GR  =  ABS(NC)  /  2 
GR  =  2**( GR  +  8) 

B( l)  =  IOR  (  LDC,  GR  ) 

B(  2)  =  IOR  (  LSM,  'OFOO'X  ) 


n  n  o  n  o  n  n  n  o  n  n  non 


STAT  -  SYS$QIOW  (  ,  %VAL(  GRJLU  ) , IO$_WRITELBLK, 
*  IOSB, ,  ,B,  %VAL(  6  ),,,,) 

RETURN 

ANY  OTHER  VALUE  FOR  IOP  IS  BAD 
1  300  CONTINUE 

WRITE(6 ,*  )  '  ERROR  MESSAGE  IOP  OUT  OF  RANGE' 
RETURN 
END 


CIOPCK  IS  A  SUBROUTINE  TO  PACK  16  BIT  DATA  BACK  INTO  BYTES 

SUBROUTINE  CIOPCK  (  B,  BUFF,  NUM  ) 

INTEGER*2  B(512),T2 
BYTE  Ti ( 2) ,  BUFF( 512) 

EQUIVALENCE  (  T2,  Tl  ) 

DO  I  =  1,  NUM 
T2  =  B( I ) 

IF  (  T2.GT.255  )  THEN 

T2  =  I AND  (  T2,  255  )  +  1 
END  IF 

BUFF(I)  =  T 1 ( 1 ) 

END  DO 
RETURN 
END 

CIOGPK  IS  A  SUBROUTINE  TO  PACK  1  BIT  OF  EACH  BYTE  OF  AN  ARRAY 
INTO  ITS  BIT  POSITION  IN  ANOTHER  ARRAY.  THIS  IS  USED  TO 
CONVERT  THE  RESULT  OF  A  GRAPHIC  READ  BACK  TO  THE  ELAS  FORMAT. 

SUBROUTINE  CIOGPK  (  B,  BUFF,  NUM  ) 

BYTE  B(512) ,  T 1 (2 ) 

INTEGER*2  T2,  BUFF(32),  MASK(16) 

EQUIVALENCE  (  T2,T1  ) 

DATA  MASK/ ' 8000 ' X , '4000’X, '2000’X, ' 1000'X, 


'800 'X,  '400 'X,  ' 200'X, 

'  100 

-x,' 

'80 'X , ' 40  'X 

, ' 20 'X , ' 10'X, 

8,4, 

2,1/ 

* 

' 8000 'X , 

'4000 'X, '2000 

’X,  ' 

1000'X, 

* 

'800'X, 

' 400 'X ,  '200' 

X,  ’ 

100 'X/ 

LOC  = 

=  1 

LOCO 

=  1 

DO  I 

=  1 

,  NUM,  16 

T2 

=  0 

DO 

J  = 

1,  16 

IF  ( 

B(  LOC) . NE.O 

)  T2  =  IOR  ( 

T2 , 

MASK(J)) 

LOC  =  LOC  +  1 
END  DO 

BUFF(LOCO)  =  T2 


LOCO  =  LOCO  +  1 
END  DO 
RETURN 
END 


kSv 


©py€>_ 

® IMHO  1 50008000®IMV005  50 1 OOOOeISTFO 1 eI S204©IC000eIT0 1000eIOP 
SUBROUTINE  RDSTAT( XLOC , YLOC , ENTER, FUNC1 ,FUNC2) 
IMPLICIT  INTEGER*2  (A  -  Z) 

INTEGER*4  SYS$ASSIGN,  SYS$QIOW,  STAT 
EXTERNAL  10$  WRITELBLK, 10$  READLBLK 


C 

C 

C 


C 

C 

C 


INTEGER*2 

GR, 

IMG, 

MASK, 

COL, 

* 

XLOC 

,  YLOC, 

* 

WID, 

LSM, 

WGD, 

WAC, 

* 

ERS, 

ERL, 

SLU, 

EGW, 

★ 

LDC  , 

NOP, 

LPR, 

LPR1 

* 

SPD , 

LPA, 

LPD, 

RPD, 

★ 

BIT1 

5 

THE  FOLLOWING  PARAMETERS  DEFINE  THE  GRINNEL  OPCODES  SYMBOLICLY 


PARAMETER 

*( WID= '0000 ' X,  LSM= ' 1000 ’X ,  WGD='2000’X, 

*  WAC= ' 2400 1 X ,  LWM= ' 2800 ' X ,  LUM='2C00'X, 
ERS= ' 3000 'X ,  ERL= ' 3400 'X ,  SLU='3800’X, 
EGW= ' 3C00 ' X ,  LER= '4000 ' X ,  LEA='4800'X, 
LEB= ' 5000 ' X,  LEC= ' 5800 'X,  LLR=’6000'X, 
LLA= ' 6800 ' X ,  LLB= 1 7000 ' X ,  LLC='7800'X, 
LDC= ' 8000 'X ,  NOP= '9000 'X,  LPR='C000'X, 
LPR1= ' C200 'X,  LPR2= 1 C400 ' X ,  LPR3= ' C600 ' X , 


*  SPD='A000'X,  LPA= ' B000 'X ,  LPD='DOOO'X,  RPD='EOOO'X, 
BIT  MASKS 


BIT10='0400'X,  B IT1 l  = ' 0800 ' X,  BIT1 5='8000 ’X) 


STAT  =  SYSSASSIGN 

( ' G  RAO : ' 

, GR  LU, ,) 

B  (  1  )  =  IOR 

( 

SPD, 

'0080'X 

) 

B( 2)  =  IOR 

( 

LPA, 

'0000  'X 

) 

B( 3)  =  IOR 

( 

RPD, 

’OOOO'X 

) 

STAT  =  SYS$Q10W( ,%VAL(GR_LU) , TO$_WRITELBLK, 
IOSB, , ,B,%VAL(6 ),,,,) 


ENTER  =  0 

FUNC1  =  0 

FUNC2  =  0 

B (  1 )  =  'OOOO'X 

B ( 2 )  =  'OOOO'X 

DO  WHILE  (ENTER  . EQ.  0) 

STAT  =  SYS$QI0W( ,%VAL(CR_LU) , I 0$_READLBLK , 
IOSB , , , B , %VAL ( 16) , , , ,) 


WRITE  (5,10)  B(  1 ) 
FO RMAT(  4X , Z4 , / ) 
PRINT  *, ’  IOSB  = 

IF  (  (B(  1)  .AND. 

ENTER  =  0 
ELSE 

ENTER  = 

END  IF 


’ ,IOSB(  1),’ 
BIT15)  .  F.Q. 


’  ,  IOSB(  2) 
0  )  THEN 


1 


END  DO 
XLOC  =  B(l) 

YLOC  =*  B( 2) 

IF  (  (  XLOC  .AND.  BIT10  )  .EQ.  0  )  THEN 
FUNC1  -  0 
ELSE 

FUNC1  -  1 
END  IF 

IF  (  (  XLOC  .AND.  BIT11  )  .EQ.  0  )  THEN 
FUNC2  -  0 
ELSE 

FUNC2  -  1 
END  IF 

XLOC  =  XLOC  .AND.  1023 
YLOC  »  YLOC  .AND.  1023 

PRINT  FI  -  ' ,FUNC1 , '  F2  =  ' ,FUNC2,'  ENT  = 

RETURN 
END 
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I’m.  '< 


ENTER 


©PY©- 

cIMHO 1 50008000®IMV00  550 10000®ISTF0 1®IS204®IC000®IT0 1000°IOP 
SUBROUTINE  TRKINT  (ENTER) 

C 

C  POLLS  TRACK  BALL  INTERFACE  TO  DETERMINE  IF  THE  ENTER  BUTTON 
C  HAS  BEEN  PUSHED.  THIS  REPLACES  DISINT  FOR  THAT  FUNCTION 


IMPLICIT  INTEGER* 2  (A  -  Z) 

INTEGER*^  ENTER 

EXTERNAL  10$  WRITELBLK, 10$  READLBLK 


INTEGER* 2 

GR,  IMG, 

MASK, 

COL, 

BUFF(512) ,  B( 600) , 

k 

XLOC ,  YLOC , 

* 

WID,  LSM , 

WGD , 

WAC, 

LWM ,  LUM, 

* 

ERS,  ERL, 

SLU, 

EGW, 

LER,  LEA, 

★ 

LDC ,  NOP, 

LPR, 

LPRl 

,  LPR2 ,  LPR3, 

k 

SPD,  LPA, 

LPD, 

RPD, 

BIT  10 ,  BIT11, 

k 

BIT  1  5 

THE  FOLLOWING  PARAMETERS  DEFINE  THE  GRINNEL  OPCODES  SYMBOLICLY . 
PARAMETER 

*( WID= ' 0000 ' X ,  LSM= ' 1 000 ' X ,  WGD='2000'X, 

*  WAC= ' 2400 ' X ,  LWM= ' 2800 ' X,  LUM='2C00'X, 

*  ERS='3000'X,  ERL= ' 3400 ' X,  SLU='3800'X, 

*  EGW='3C00'X,  LER=  '  4000  'X  ,  LF.A=  ’  4800 'X , 

*  LEB= ' 5 000 ' X ,  LEC=' 5800 'X,  LLR='6000'X, 

*  LLA= ' 6800 'X ,  LLB=  '  7000  'X ,  LLC='7800'X, 

*  LDC= 1 8000 'X ,  NOP= ' 9000 ' X ,  LPR='C000'X, 

*  LPR 1= ' C 200 ' X ,  LPR2= ' C400 ' X ,  LPR3= ' C600 ' X , 

*  SPD= ' A000 ' X ,  LPA= ' BOOO ' X ,  LPD='DOOO'X,  RPD='EOOO'X, 

HIT  MASKS 

*  B IT  10= ' 0400 'X ,  BIT  1 1 = ' 0800 ' X ,  BIT1 5= '8000 ’X) 

STAT  =  SYS$ASSIGN  ( ' G RAO : ' , G R_LU , , ) 

B( 1  )  =  IOR  (  SPD ,  '0080 'X  ) 

B(2)  =  IOR  (  LPA,  ’OOOO'X  ) 

B ( 3 )  =  TOR  (  LPR,  '0011 'X  ) 

B( 4 )  =  IOR  (  RPD,  'OOOO'X  ) 

STAT  =  SYS$QIOW( ,%VAL(GR_LU) ,IO$_WRI TELBLK, 

*  IOSB , , , B , %VAL( 8 ) , , , , ) 

ENTER  =  0 


DO  WHILE  ( I  ENTER 


,  AND.  (JUNK  .LE.  ^00)) 


STAT  =  SYS$QIOW( ,%VAL(GR_LU) , IO$_READLBLK, 
IOSB, , ,B,%VAL( 16) , , , ,) 

WRITE  (5, 10)  B( 1 ) 

FORMAT  (4X.Z4  ,/) 

IF  (  ( B( 1 )  .AND.  BIT  1 5 )  . EQ.  0  )  THEN 
ENTER  =  0 


'  ■'  ■'•  ■W*'’  -V>  .rAAbV.S  '  -J.  'J. 


.A  *  t/  -i 


ELSE 

ENTER  -  1 
END  IF 
C 

C  END  DO 

C 

PRINT  ENTER  =  '.ENTER 

RETURN 

END 


>  \ 


©py©_ 

®IMHO 1 50008000® IMVOO 550 1000O®ISTF01®IS204®IC000®IT01O00®IOP 
SUBROUTINE  ZOOM 
IMPLICIT  INTEGER*2  (A  -  Z) 

INTEGER*4  SYS$ASSIGN, SYS$QIOW, STAT 
EXTERNAL  IO$_READLBLK,  IO$_WRITELBLK 

INTEGER* 2  GR,  IMG,  MASK,  COL,  BUFF(512),  B(600) ,  IOSB(4), 

*  XLOC ,  YLOC , 

*  WID,  LSM,  WGD ,  WAC,  LWM ,  LUM, 

*  ERS,  ERL,  SLU,  EGW,  LER,  LEA, 

*  LDC ,  NOP,  LPR,  LPR1 ,  LPR2,  LPR3, 

*  SPD,  LPA,  LPD,  RPD,  BITIO,  BIT11, 

*  BIT15 


C 

C 

C 


C 

C 


C 


C 


THE  FOLLOWING  PARAMETERS  DEFINE  THE  GRINNEL  OPCODES  SYMBOLICLY . 
PARAMETER 

*(WID='0000'X,  LSM= ' 1 000 ' X ,  WGD='2000'X, 

*  WAC= ' 2400 ' X ,  LWM= ' 2800 ' X ,  LUM='2C00'X, 

*  ERS=’ 3000'X,  ERL=' 3400 ' X,  SLU='3800'X, 

*  KGW= ' 3C00 ' X ,  LER= ' 4000 1 X ,  LEA='4800'X, 

*  LEB= ' 5000 ' X ,  LEC= ' 5800 ' X,  LLR='6000'X, 

*  LLA= ' 6800 ' X ,  LLB= ' 7000 ' X ,  LLC='7800'X, 

*  LDC= ' 8000 ' X ,  NOP='9000’X,  LPR='C000'X, 

*  LPR1 = 1 C200 1 X ,  LPR2= 1 C400 1 X ,  LPR3= ' C600 'X , 

*  SPD= ' AOOO ' X ,  LPA= ' BOOO  'X ,  LPD='D000'X,  RPD=’E000'X) 


STAT  =  SYS$ASSIGN  ( 'GRAO: ’ ,GR  LU, , ) 


PRINT  * 
PRINT  * 
PRINT  * 
PRINT  * 
PRINT  * 
PRINT  * 
PRINT  * 
PRINT  * 
PRINT  * 
PRINT  * 
PRINT  * 
PRINT  * 
PRINT  * 
PRINT  * 


TURN  FUN  A  SWITCH  OFF' 

» 

I 

DEPRESS  ENTER  TO  ZOOM 
» 

ZOOM  VALUES  SEQUENCE  THRU  MODULO  (1,  2,  4,  8)  ' 
» 

f 

TURN  FUN  A  ON  THEN  DEPRESS  ENTER  TO  QUIT' 

» 

f 

MOVE  TRACK  THEN  DEPRESS  ENTER  TO  SCROLL' 


X  =  0 
Y  =  0 
ENTER  =  0 
FUN Cl  =  0 
FIJNC2  =  0 


CALL  RDSTAT(X,Y, ENTER, FUNC1 ,FUNC2) 
FNC2HD  =  0 


C 


CHAN  =  0 
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>» 


l-'.’.VVQ 


DO  WHILE  (FUNC1  .EQ.  0) 


ZMVAL 
ZMVAL 
ZOOMV 
B(  1 ) 
B(2) 

B(  3) 
ZOOMV 
B(4)  = 
B(5 )  = 
B(6)  = 
B(7)  = 
INSTCT 


=  ZMVAL  +  ENTER 
=  MOD  (ZMVAL,  4) 

=  ZMVAL 

=  I OR  (  SPD,  '0100'X  ) 

=■  IOR  (  LPR,  ' OOOF'X  ) 

=  IOR  (  SPD,  *0008'X  ) 

=  IOR  (  ZOOMV,  '004C'X  ) 

IOR  (  LPR,  ZOOMV  ) 

IOR  (  LPA,  '0000 'X  ) 

IOR  (  LPD,  X  ) 

IOR  (LPD,  Y  ) 

=  14 


IF  ( FUNC2  .NE.  FNC2HD)  THEN 
CHAN  =  CHAN  +  1 
CHAN  =  MOD  (CHAN,  3) 

FCHAN  =  IOR  ( 2**CHAN ,  'OFOO'X) 

FNC2HD  =  FUNC2 

B( 8)  =  IOR  (  LDC ,  FCHAN  ) 

INSTCT  =  INSTCT  +  2 
END  IF 

STAT  =  SYS$QIOW( ,%VAL(GR_LU) ,IO$_WRITELBLK 
*  IOSB, , ,B,%VAL( INSTCT),,,, 

CALL  RDSTAT( X , Y, ENTER, FUNC 1 , FUNC2 ) 

END  DO 

CENTER  IMAGE  ON  SCREEN  WITH  ZOOM  VALUE  OF  1 

X  =  255 
Y  =  255 


B(  l) 

=  IOR  (  SPD, 

’0100'X 

B(  2  ) 

=  IOR  (  LPR, 

' 000F  'X 

B(  3) 

=  IOR  (  SPD, 

’0008'X 

B(4) 

=  IOR  (  LPR, 

'004CX 

B(  5  ) 

=  IOR  (  LPA, 

'0000'X 

B(6) 

=  IOR  (  LPD, 

X 

B(  7 ) 

=  IOR  (  LPD, 

Y 

INSTCT  =  14 


SYS$Q IOW(  ,%VAL( GR__LU)  , I 0$_WRTTELBLK, 
IOSB,  ,  ,  B/ZVALC  INSTCT)  ,  ,  ,  ,  ) 


RETURN 

END 


UNCLASSIFIED 


SECURITY  CLASSIFICATION  OF  THIS  PAGE 


REPORT  DOCUMENTATION  PAGE 


la  REPORT  SECURITY  CLASSIFICATION 

Unclassified 


2a  SECURITY  CLASSIFICATION  AUTHORITY 


2b  DECLASSIFICATION/DOWNGRADING  SCHEDULE 


4  PERFORMING  ORGANIZATION  REPORT  NUMBER(S) 

NORDA  Report  203 


6  NAME  OF  PERFORMING  ORGANIZATION 


1b.  RESTRICTIVE  MARKINGS 

None 


3.  DISTRIBUTION/AVAILABILITY  OF  REPORT 

Approved  for  public  release;  distribution  is 
unlimited. 


5  MONITORING  ORGANIZATION  REPORT  NUMBER(S) 

NORDA  Report  203 


7a  NAME  OF  MONITORING  ORGANIZATION 


Naval  Ocean  Research  and  Development  Activity  Naval  Ocean  Research  and  Development  Activity 


6c  ADDRESS  (City,  State,  and  ZIP  Code) 

Ocean  Science  Directorate 
NSTL,  Mississippi  39529-5004 


7b  ADDRESS  (City,  State,  ana  ZIP  Code I 

Ocean  Science  Diiectorate 
NSTL,  Mississippi  39529-5004 


10  SOURCE  OF  FUNDING  NOS. 


8a  NAME  OF  FUNDING/SPONSORING  ORGANIZATION  8b.  OFFICE  SYMBOL  9  PROCUREMENT  INSTRUMENT  IDENTIFICATION  NUMBER 

Naval  Ocean  Research  and  inapplicable) 

Development  Activity 


8c  ADDRESS  (City.  Slate,  and  ZIP  Code I 

Ocean  Science  Directorate 
NSTL,  Mississippi  39529-5004 


1 1  title  (Include  Security  Classification) 

Implementation  Issues  for  Level  0  Image  Processor  Software  within  an  Application  Package 


12  PERSONAL  AUTHOR(S) 

James  E.  Lennox 


PROGRAM 

PROJECT 

TASK 

WORK  UNIT 

ELEMENT  NO. 

NO 

NO. 

NO. 

63704N 

R1987 

300 

23508B 

13a  TYPE  OF  REPORT 

Final 


16  SUPPLEMENTARY  NOTATION 


13b  TIME  COVERED 
From _ To 


14  DATE  OF  REPORT  (Yr..  Mo  .  Day ) 

February  1988 


15  PAGE  COUNT 

30 


17 

COSATl  CODES 

FIELD 

GROUP 

SUB  GR  1 

’8  SUBJECT  TERMS  (Continue  on  reverse  if  necessary  and  identify  by  block  number) 

image  processing,  software,  hardware,  ELAS,  ERL,  PAL, 
Landsat,  Thematic  Mapper  data,  VAX  11/780,  VAX  11/750 
modules,  callable  subroutines,  COMD,  pixel 


19  ABSTRACT  / Continue  on  reverse  it  necessary  and  identify  by  block  number ) 

Image  processing  is  rapidly  emerging  as  a  field  with  many  interesting  areas  for  the  computer  scien¬ 
tist.  Packages  are  available  that  allow  images  to  be  manipulated  in  an  interactive  environment  by  applying 
functions  to  the  image.  Functions  are  defined  as  transformations  from  the  image  memory  domain  to 
the  display  domain,  which  may  permanently  alter  image  memory  values.  This  paper  describes  minimum 
hardware  constraints  and  the  scope  of  modifications  necessary  to  implement  different  image  processors 
within  the  Earth  Resources  Laboratory  Applications  Software  (ELAS)  software  environment.  It  also  con¬ 
trasts  the  impact  on  software  engineering  principles  related  to  the  implementation  of  low-level  soft¬ 
ware  to  support  the  imaging  functions. 


20  DISTRIBUTION/AVAILABILITY  OF  ABSTRACT 
UNCLASSIFIED/UNLIMITED  SAME  AS  RPT 


22a  NAME  OF  RESPONSIBLE  INDIVIDUAL 

James  E.  Lennox 


DD  FORM  1473.  83  APR 


21  ABSTRACT  SECURITY  CLASSIFICATION 

Unclassified 


22b  TELEPHONE  NUMBER  (Include  Area  Code ) 

(601)  688-4633  _ 


EDITION  OF  1  JAN  73  IS  OBSOLETE 


22c  OFFICE  SYM80L 

Code  351 


_ UNCLASSIFIED 

SECURITY  CLASSIFICATION  OF  THIS  PAGE 


& 


